index (DB)

1つのtable内の、1つ以上のcolumnに対して作る

大きくrecordを絞り込める検索条件が存在する場合のみ有効

実際のtableとは別に、検索に適した形にしたメタデータのtableを作る

検索する際は、そのメタデータのtableを参考にして検索する

例えば、以下のようなtableがあった時

table:order

order_id price date

1 1000 ..

2 3000 ..

3 2500 ..

.. .. ..

そこで、以下のようにpriceでsortしたメタデータを管理するtableを別途用意する

table:meta

price order_id

1000 1

2500 3

3000 2

3000 10

... ...

sortされているので、全record見る必要がなくなった

このmeta tableをいくつかのレンジごとに分割するとさらに効率が良くなる

...

これはまさにtree構造をやっているのと同じ

こういう感じのことをやっているのがindex

トレードオフがかなりある

追加/更新/削除する場合は、Indexも更新する必要があるため時間がかかる

検索の場合も、常に速くなるとは限らない

検索条件や、データの分布によってはfull scanした方が速いこともある

そのため、仕組みとユースケースを見比べて設計する必要がある

以下のようなcolumnは自動的にindexが作られる

主キー

外部キー

UNIQUE制約があるcolumn

そのため、これらに自分でIndexを作っても無意味

代表的なアルゴリズム

ほぼこれ

参考

概要。説明の流れがめっちゃ良い

基本

indexの本

構文

code:sql

CREATE INDEX <index名> ON <table名>(<column名>)

code:sql

DROP INDEX <index名> ON <table名>

型の指定の仕方でindexの効用って変化する？

1つのtableに対し、2つのindexを作ると、2つのツリーができる？

ということは更新時にはより遅くなる？

↑で向き不向きがあるのね

B-treeはBETWEEN検索に有効

AND, OR, NOT検索はビットマップインデックスが有効

どのタイミングで更新されるのか

追加・更新・削除があると毎回創るのか

ちょっとバッジ的にまとめて更新することもできるのか

複数のインデックスを併用することってできるの？

indexを作った場合、基本的にsortしたツリーが別途作られるってこと？

sort以外にあるのかな

1table内の複数のcolumnにindexを作る